FIG. 1 is a network structure of an LTE (Long Term Evolution) system, the related art mobile communication system. For the LTE system, which has evolved from the existing UMTS system, basic standardizations are ongoing in the 3GPP.
An LTE network can be divided into an E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) and a CN (Core Network). The E-UTRAN includes a terminal (or UE (User Equipment)), a base station (eNB (Evolved NodeB), and an access gateway (aGW). The access gateway may be divided into a part that handles processing of user traffic and a part that handles control traffic. In this case, the access gateway part that processes the user traffic and the access gateway part that processes the control traffic may communicate with each other by using a new interface. One or more cells may exist in a single eNB. An interface for transmitting user traffic or control traffic may be used between eNBs. The CN may include the access gateway and a node or the like for user registration of the UE. An interface for discriminating the E-UTRAN and the CN may be used.
FIG. 2 shows an exemplary structure of a control plane of a radio interface protocol between the UE and the E-UTRAN based on the 3GPP radio access network standards. FIG. 3 shows an exemplary structure of a user plane of the radio interface protocol between the UE and the E-UTRAN based on the 3GPP radio access network standards.
The structure of the radio interface protocol between the UE and the E-UTRAN will now be described with reference to FIGS. 2 and 3.
The radio interface protocol has horizontal layers comprising a physical layer, a data link layer, and a network layer, and has vertical planes comprising a user plane (U-plane) for transmitting data information and a control plane (C-plane) for transmitting control signals. The protocol layers in FIGS. 2 and 3 can be categorized as a first layer (L1), a second layer (L2), and a third layer (L3) based on three lower layers of an open system interconnection (OSI) standard model widely known in the communication system. The radio protocol layers exist as pairs between the UE and the E-UTRAN and handle a data transmission in a radio interface.
The layers of the radio protocol control plane of FIG. 2 and those of the radio protocol user plane in FIG. 3 will now be described as follows.
The physical layer, the first layer, provides an information transfer service to an upper layer by using a physical channel. The physical layer is connected to an upper layer called a medium access control (MAC) layer via a transport channel. Data is transferred between the MAC layer and the physical layer via the transport channel. The transport channel is divided into a dedicated transport channel and a common channel according to whether or not a channel is shared. Between different physical layers, namely, between a physical layer of a transmitting side and that of a receiving side, data is transferred via the physical channel.
The second layer includes various layers. First, a medium access control (MAC) layer serves to map various logical channels to various transport channels and performs logical channel multiplexing by mapping several logical channels to a single transport channel. The MAC layer is connected to an upper layer called a radio link control (RLC) layer by a logical channel. The logical channel is divided into a control channel that transmits information of the control plane and a traffic channel that transmits information of the user plane according to a type of transmitted information.
An RLC (Radio Resource Control) layer, the second layer, segments or concatenates data received from an upper layer to adjust the data size so as for a lower layer to suitably transmit the data to a radio interface. In addition, in order to guarantee various QoSs required by each radio bearer RB, the RLC layer provides three operation modes: a TM (Transparent Mode); a UM (Unacknowledged Mode); and an AM (Acknowledged Mode). In particular, the RLC layer operating in the AM (referred to as an ‘AM RLC layer’, hereinafter) performs a retransmission function through an automatic repeat and request (ARQ) function for a reliable data transmission.
A packet data convergence protocol (PDCP) layer of the second layer performs a function called header compression that reduces the size of a header of an IP packet, which is relatively large and includes unnecessary control information, in order to effectively transmit the IP packet such as an IPv4 or IPv6 in a radio interface having a smaller bandwidth. The header compression increases a transmission efficiency between radio interfaces by allowing the header part of the data to transmit only the essential information.
The RRC layer located at the uppermost portion of the third layer is defined only in the control plane, and controls a logical channel, a transport channel and a physical channel in relation to configuration, reconfiguration, and the release or cancellation of radio bearers (RBs). Here, the RBs refer to a logical path provided by the first and second layers of the radio protocol for data transmission between the UE and the UTRAN. In general, the set-up (configuration) of the RB refers to the process of stipulating the characteristics of a radio protocol layer and a channel required for providing a particular data service, and setting the respective detailed parameters and operation methods.
FIG. 4 shows a PDCP entity structure. Hereinafter, the PDCP entity will now be described in detail. In this respect, however, the blocks as shown in FIG. 4 are functional blocks which may be different from those actually implemented.
The PDCP entity is upwardly connected with the RRC layer or a user application, and downwardly connected with the RLC layer. Its detailed structure is as follows.
A single PDCP entity includes a PDCP transmitting side and a PDCP receiving side. The left transmitting side configures an SDU received from an upper layer as a PDU or configures control information generated by the PDCP entity itself as a PDU and transmits the same to the receiving side of the peer PDCP entity, and the right receiving side extracts the PDCP SDU or the control information from the PDCP PDU received from the transmitting side of the peer PDCP entity.
As mentioned above, the PDU generated by the transmitting side of the PDCP entity includes two types of PDUs: a data PDU and a control PDU. First, the PDCP data PDU is a data block created by processing the SDU received from the upper layer by the PDCP; and the PDCP control PDU is a data block generated by the PDCP itself to transfer control information to the peer entity.
The PDCP Data PDU is generated from RBs of both the user plane and the control plane, and some functions of the PDCP are selectively applied according to a plane in use. Namely, a header compression function is applied only for the user plane data, and an integrity protection function among security functions is applied only for the control plane data.
Besides the integrity protection function, the security function also includes a ciphering function for maintaining the security of data. The ciphering function is applied to both the user plane data and the control plane data.
The PDCP control PDU is generated only at the user plane RB and includes two types: a ‘PDCP status report’ for informing the transmitting side about a PDCP reception buffer status and an ‘HC (Header Compression) feedback packet’ for informing a header compressor about a status of a receiving side header decompressor.
FIG. 5 is a block diagram showing a procedure of processing each PDCP PDU in the PDCP entity.
Specifically, FIG. 5 shows the process of how the three types of PDCP PDUs, namely, the PDCP data PDU, the PDCP control PDU for PDCP status report, and a PDCP control PDU for HC feedback, are processed through a path to a path, {circumflex over (8)}. The PDCP processing paths with respect to the respective PDUs are as follows.
1. The processing of the PDCP data PDU in the PDCP entity relates to the paths {circumflex over (1)}, {circumflex over (3)} and {circumflex over (7)}. Each path will now be described.
Path {circumflex over (1)}: The transmitting side PDCP performs header compression and security on the SDU received from the upper layer, configures a PDCP data PDU by adding a PDCP SN (Sequence Number), a D/C field indicating whether or not a PDU is a data PDU or a control PDU, or the like to a header, and transmits the same to the receiving side PDCP (namely, the peer PDCP). The header compression may be performed by a header compressor.
Path {circumflex over (8)}: The receiving side PDCP first removes the header of the PDCP data PDU received from the lower layer, performs a security check and header decompression on the PDCP data PDU to restore the PDCP SDU, and transfers the same to an upper layer. In this case, the PDCP SDU is delivered to the upper layer in sequence, and if the PDCP SDU has been received out of sequence, it is reordered in a reception buffer and then delivered to the upper layer. The header decompression may be performed by a header decompressor.
Path {circumflex over (3)}: The transmitting side PDCP may piggyback an HC feedback packet to the PDCP data PDU and transmit the same (e.g., the HC feedback packet is added to or included in the PDCP data PDU and then transmitted). In this case, as for the HC feedback packet, information is received from header decompression of the receiving side PDCP co-located with the transmitting side PDCP, and when the PDCP SDU received from the upper layer is header-compressed, the HC feedback packet is piggybacked thereto to configure a packet. Thereafter, the PDCP SDU and the piggybacked HC feedback packet are subject to security, and the PDCD SN, the D/C field, or the like, are added to the header to configure a PDCP data PDU, which is then transmitted from the transmitting side PDCP to the receiving side PDCP.
Path {circumflex over (7)}: When the receiving side PDCP receives the PDCP data PDU, it removes its header and performs security checking and header decompression thereon to restore the PDCP SDU. At this time, if the piggybacked HC feedback packet exists, the receiving side PDCP extracts it and transfers it to the header compression of the co-located transmitting side PDCP. Then, the header compression of the transmitting side PDCP can determine whether to transmit a next packet with a full header or a compressed header according to the feedback information.
2. The processing of the PDCP control PDU for the PDCP status report in the PDCP entity relates to the path {circumflex over (2)} and the path {circumflex over (5)}. Each path will now be described.
Path {circumflex over (2)}: the receiving side PDCP may check a reception buffer and if there is a PDCP SDU that has not been received, the receiving side PDCP may request its re-transmission from the transmitting side of the PDCP. In this case, the status of the reception buffer is configured as a PDCP status report, and the configured PDCP status report is transmitted in the form of a control PDU to the co-located transmitting side of the PDCP. The header of the PDCP control PDU includes the D/C field indicating whether a PDU is a data PDU or the control PDU and a CPT (Control PDU Type) field indicating whether the control PDU includes the PDCP status report or the HC feedback packet.
Path {circumflex over (5)}: When the receiving side PDCP receives the PDCP control PDU including the PDCP status report, it transfers the received PDCP status report to the co-located transmitting side PDCP. The co-located transmitting side PDCP re-transmits a PDCP SDU that its peer receiving side PDCP has not received, based on the PDCP status report.
3. The processing of the PDCP control PDU for HC feedback in the PDCP entity relates to the path {circumflex over (4)} and the path {circumflex over (6)}. Each path will now be described.
Path {circumflex over (4)}: The transmitting side PDCP may include the HC feedback packet in the PDCP control PDU, rather than piggybacking it to the PDCP data PDU, and independently transmit it. In this case, the information about the HC feedback packet is received from header decompression of the receiving side PDCP which is co-located with the transmitting side PDCP. The HC feedback packet may be configured into the PDCP control PDU by adding the D/C field and the CPT field to the header, and then transmitted to the receiving side of the peer PDCP.
Path {circumflex over (6)}: When the receiving side PDCP receives the PDCP control PDU including the HC feedback packet, it transfers the same to the header compression of the co-located transmitting side PDCP. Then, the header compression of the transmitting side PDCP may determine whether to transmit a next packet with a full header or a compressed header according to the feedback information.
As mentioned above, the PDCP may transmit the two types of information, i.e., the status report and the HC feedback, with the control PDU. If the two types of information are simultaneously transmitted, they are configured as independent control PDUs and then transmitted. If various control information are transmitted in the form of the respective independent control PDUs, the size of the headers is increased.
Namely, the PDCP layer requires headers each indicating each control information, and the RLC layer, the lower layer of the PDCP layer, requires a length indicator for informing about the size of each PDCP control PDU in the header, resulting in an increase in the size of the headers.